【資料公開】AthenaとStep Functionsで簡単ETLオーケストレーション #midosuji_tech
2024.06.15データアナリティクス事業本部 インテグレーション部 機械学習チームの鈴木です。
2024年6月12日にクラスメソッドの大阪オフィスで開催された勉強会Midosuji Tech #1で『AthenaとStep Functionsで簡単ETLオーケストレーション』というタイトルで話しましたので資料を公開します。
当日は淀屋橋の大阪オフィスでオンサイトでイベントが開催されました。発表後にはワイワイガヤガヤタイムということで、参加者の方も交えたディスカッションが大変盛り上がりました。
発表資料
ポイント
Step FunctionsのAPI統合で、S3バケットに配置したSQLファイルをステートマシンから読み込み、Athenaで実行する仕組みを紹介しました。昔からAWSを使っている方だとLambdaをステートマシン内で呼び出し、Lambda関数でS3バケットからのファイルの読み込みやAthenaでの実行をイメージする方もいるかと思いますが、API統合を利用することで関数なしで実現できるようになっています。
また、Step FunctionsからAthenaのStartQueryExecution APIを同期呼び出しできるようにもなっていたので、こちらにも言及しました。（私が知らなかっただけかもですが...）
限られた小さな仕組みとして運用するだけなら上記の構成で十分便利なのですが、実際のところより運用しやすくしたり、今後求められるデータマネジメントの要件に対応するためには、データリネージやデータ品質管理などを実現する方法も求められます。Athenaは一度に大量のパーティションを作成することはできないので、パーティション分割した時系列のデータについて過去データを再作成したい場合にはRedshiftを採用することも視野にいれようということもご紹介しました。
討議内容と補足
当日は参加者の方と討議できる時間もあっため、そこで出た発表に関する内容と補足を記載します。当日は私以外にもAthenaの話をしたメンバーがいたため、Athenaに関する内容が多く出ました。
Redshiftの方がよい場合をもう少し聞きたい
発表内容の流れで、Redshiftの方がよい場合をご紹介しました。
ご紹介したdbtにまつわるところだと、コネクタとdbtでインストールできるパッケージの互換性です。
Redshiftはコネクタをdbt Labsがメンテナンスしていることもあってか多くの場合にパッケージがサポートしているものの、dbt-athena-communityはサポートされていない場合があり、実行してみると動かないということがありました。dbt-athena-communityが悪いわけではないのですが、パッケージもあらゆるコネクタに対応できないと思うので仕方ないと思います。
データ再作成についてだと、ロジック改修でテーブルを再作成する場合に作成済みのテーブルをrenameして新旧を入れ替えることができますが、Redshiftではテーブル名だけを変えればよいものの、Athenaの場合はGlueテーブル名を変えてもS3バケットのデータのパスは変わらないので、S3バケット上のデータのパスにも気を配らないと不整合が起こるということもあります。発表で紹介した１度に作成できるのが100パーティションまでのクォータもありますがRedshiftでは気にする必要はありません。
Athenaの速度向上について
SQLの見直しやキャパシティ予約、列統計の使用により高速化することは可能です。
- Amazon Athena キャパシティ予約ができるProvisioned Capacityについて徹底解説！ | DevelopersIO
- Optimizing query performance using column statistics - AWS Glue
また、以下のAWSブログで公開されているパフォーマンスチューニングTipsも必見です。
Icebergテーブルのタイムトラベルの使い所
タイムトラベルにより、スナップショットが保存されている範囲で、過去の特定時点のデータにアクセスすることができます。
過去の状態を使いたいケースは多いと思うので、活躍する場面はたくさんありますが、例えば日々UPSERTされているテーブルに対して調査を行う場合に、特定時点のデータの確認がしやすいメリットがあります。
一方でスナップショットが残ってしまうことが課題となるケースもあると考えています。例えば以下のSnowflakeの記事で紹介されているようなケースです。
EU一般データ保護規則（GDPR）ではユーザーは忘れられる権利を認められているため、一般的に組織は要求後30日、場合によっては90日後に個人情報をデータベースから削除する必要があります。
このようなケースに対応するためには、適切にテーブルのタイムトラベル期間を設計・設定しておく必要があります。
MSCK REPAIR TABLEとはなんですか
Hive互換のパーティションをS3バケットに追加した場合に、Glueデータカタログにメタデータを追加するためのコマンドになります。
Hive互換のパーティションとは、例えばs3://DOC-EXAMPLE-BUCKET/path/userId=1/のような形式のプレフィクスです。
MSCK REPAIR TABLEは非常に便利なコマンドですが、パーティション数が非常に多い場合は実行に時間がかかることに加え、あまりにも多い場合はタイムアウトすることもあります。ただし、そのような場合は基本的にはパーティションキーのカーディナリティが多いので、そのようなキーはパーティショニングに使わないか、Icebergテーブルにテーブルフォーマットを変えてハッシュによるhidden partitioningを使うのがよいと思います。（Hiveテーブルではバケッティングが使えますが、CTASのみサポートされています）
最後に
2024年6月12日にクラスメソッドの大阪オフィスで開催された勉強会Midosuji Tech #1の発表資料のご紹介でした。
![[アップデート] Amazon WorkSpaces Personalにアイドル切断タイムアウトが導入されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-acc3ac1234c3f431604b3ef32a527e4a/ef41ff2367e43f0b972b2ceec4893544/amazon-workspaces-family)
